<html>
<head><meta charset="utf-8"><title>Deref Patterns (but now a project group) · project-deref-patterns · Zulip Chat Archive</title></head>
<h2>Stream: <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/index.html">project-deref-patterns</a></h2>
<h3>Topic: <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html">Deref Patterns (but now a project group)</a></h3>

<hr>

<base href="https://rust-lang.zulipchat.com">

<head><link href="https://rust-lang.github.io/zulip_archive/style.css" rel="stylesheet"></head>

<a name="229527472"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229527472" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229527472">(Mar 09 2021 at 18:24)</a>:</h4>
<p>Given that this is now a project group, and work can officially start, I'm going to use this opportunity to bring back up the major questions of the feature, and the updates from the MCP process.<br>
A previous consolidation of the discussions for this can be found on <a href="https://hackmd.io/@wSaA8OrrSQ2SlegMvA6e6A/S1VwlyCRD">this hackmd</a>.  <br>
Syntax:</p>
<ul>
<li>The syntax question is still open, which the major options being: Having No syntax, using a sigil, and using a keyword. Pros and cons of each are detailed in the above hackmd and can be discussed furhter<br>
     *  A keyword may be the most obvious, but, except for reusing the existing <code>box</code> keyword, it would require reversing a new one in a new edition, which locks the feature out of at least 2015 and 2018 editions, possibly 2021 as well (if anyone has insight as to whether or not it would be viable to reserve a keyword for 2021 edition, that may be helpful). Additionally, the obvious keyword "<code>deref</code>" is presumably a non-starter, as it is the name of a stdlib trait method (and of the trait that Deref Patterns works with)</li>
<li>Some combination of the above options (in particular, no sigil/keyword in a subset of cases, and requiring one in all others) is also an option</li>
</ul>
<p>Soundness and Exhaustiveness:</p>
<ul>
<li>Allowing arbitrary, user-defined, Deref and DerefMut implementations would require that deref patterns be treated as non-exhaustive for soundness purposes. In preliminary discussions of the feature were: to not make deref patterns exhaustive, to limit only to standard library types, and to define a new unsafe trait <code>DerefPure</code>, which provides a necessary contract for soundness of exhaustive pattern matching.</li>
<li>For this project, the lang team has instructed that <code>DerefPure</code> <em>not</em> be persued, and that deref patterns will be limited to a subset of standard library types. The project will determine and propose a set of rules for standard library types that participate in deref patterns, and will propose an initial list of standard library types, subject to T-lang and T-libs approval. </li>
</ul>
<p><span class="user-mention" data-user-id="245339">@Nadrieril</span>, I believe you previously expressed interest in participating in the MCP and Project Group. Are you still interested in working on this?</p>



<a name="229528533"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229528533" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229528533">(Mar 09 2021 at 18:31)</a>:</h4>
<p>Note that we didn't rule out all future possibility of allowing this for user types; we're just suggesting that the <em>initial</em> version should focus on standard types.</p>



<a name="229529074"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229529074" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229529074">(Mar 09 2021 at 18:34)</a>:</h4>
<p>Also, FWIW, I think "no sigil for literals, sigil for non-literals" should be a contender as well. I'd expect literals to be a <em>very</em> common case of this, and they're also the case where a sigil provides the least value.</p>



<a name="229534218"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229534218" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229534218">(Mar 09 2021 at 19:07)</a>:</h4>
<p><code>deref</code> as the keyword has some nice symmetry with the <code>ref</code> keyword. the overlap with <code>.deref()</code> is unfortunate, but there's no technical reason why a keyword couldn't be contextual rather than reserved.</p>



<a name="229534633"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229534633" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229534633">(Mar 09 2021 at 19:10)</a>:</h4>
<p>more generally I'm in favor of a keyword rather than a sigil, for reasons that are probably out of scope for this proposal. to elaborate, I like the idea of being able to use the chosen keyword in non-pattern contexts as a replacement for <code>*</code>, whose prefix nature gets awkward with method chaining; in the same way that <code>.await</code> is postfix, we could have a <code>.deref</code> postfix keyword for this use case. of course, this isn't exactly urgent, since you can technically do <code>.deref()</code> today already in method chains :P</p>



<a name="229534867"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229534867" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229534867">(Mar 09 2021 at 19:11)</a>:</h4>
<p>Isn't there a potential ambiguity? I don't know off the top of my head.</p>



<a name="229535260"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229535260" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Nadrieril <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229535260">(Mar 09 2021 at 19:14)</a>:</h4>
<p>I still want to help out if I can, but I can't commit to anything sadly :/</p>



<a name="229536392"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229536392" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229536392">(Mar 09 2021 at 19:20)</a>:</h4>
<p>ambiguity with regard to having the keyword be contextual rather than reserved? I don't think it's an insurmountable challenge, but it would take some care. the good news is that most method and function calls are illegal in pattern context, so the actual <code>Deref::deref</code> would remain unambiguous to parse. the only problem I would foresee is if someone wrote something like <code>enum Foo { deref(i32, i32) }</code>, in which case a pattern like <code>deref (4, 4)</code> would be syntactically ambiguous. the same thing applies to tuple structs like <code>struct deref(i32, i32)</code>. you would want a rule where users are forbidden from defining enum variants or tuple structs named <code>deref</code>. other than that, you would disambiguate on whether you're in pattern or expression context. that said, if there's a better keyword, that would be easier to implement :)</p>



<a name="229537541"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229537541" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229537541">(Mar 09 2021 at 19:26)</a>:</h4>
<p>In any case, it would most likely require an edition boundary.</p>



<a name="229537711"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229537711" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229537711">(Mar 09 2021 at 19:27)</a>:</h4>
<p>true, but that's the case for any new keyword</p>



<a name="229538209"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229538209" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Connor Horman <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229538209">(Mar 09 2021 at 19:30)</a>:</h4>
<p>The problem is that it would delay deref patterns to 2024 edition, unless the proposal for the reservation can be drafted, submitted as an RFC, and fcp merged before whatever deadline exists for edition 2021. I don't know that doing such would be reasonable.</p>



<a name="229538812"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229538812" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229538812">(Mar 09 2021 at 19:33)</a>:</h4>
<p>well, keywords can be provisionally reserved long before their RFCs are accepted; the 2018 edition reserved <code>async</code> and <code>await</code>, which didn't have accepted RFCs at the time of the edition. given that this RFC is a successor to <code>box</code> patterns, I think it's clear that this is something that's generally desirable and doesn't really need to do much work to justify itself. so <em>if</em> a keyword for this can be decided upon relatively soon, I don't think it would be too much of a stretch to ask that it be reserved long before your proposal is finalized</p>



<a name="229539355"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229539355" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229539355">(Mar 09 2021 at 19:36)</a>:</h4>
<p><span class="user-mention" data-user-id="256342">@bstrie</span> We have a policy now (developed largely because of the problems from those keywords) against reserving keywords before we have a concrete feature proposal on the table.</p>



<a name="229539658"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229539658" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229539658">(Mar 09 2021 at 19:37)</a>:</h4>
<p>how about <code>chase</code>? dereferencing is often called "pointer chasing", so it avoids having to invent new terminology. it's also short, unabbreviated, relatively unlikely to be used as an identifier in existing code</p>



<a name="229539835"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229539835" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229539835">(Mar 09 2021 at 19:38)</a>:</h4>
<p>Making up new keywords doesn't seem very helpful - it won't fix the ambiguity and it means people are less likely to recognize it</p>



<a name="229539879"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229539879" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229539879">(Mar 09 2021 at 19:39)</a>:</h4>
<p>I think deref is better than chase for that reason</p>



<a name="229539920"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229539920" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229539920">(Mar 09 2021 at 19:39)</a>:</h4>
<p>it does fix the ambiguity in a sense: we can make the keyword reserved rather than contextual, which we can't do for <code>deref</code> because that would break std</p>



<a name="229540700"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229540700" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229540700">(Mar 09 2021 at 19:45)</a>:</h4>
<p>(technically you <em>could</em> make <code>deref</code> a reserved keyword if you deprecated-and-renamed <code>Deref::deref</code> to something else, and then introduced the <code>deref</code> keyword only on edition X, and then made it a compiler error to access <code>Deref::deref</code> on edition X (using mechanisms akin to what <a href="https://github.com/rust-lang/rfcs/pull/3088">this RFC</a> proposes), but this would be both highly disruptive and take years to achieve.)</p>



<a name="229541342"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229541342" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> scottmcm <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229541342">(Mar 09 2021 at 19:49)</a>:</h4>
<p>(Being able to implement things as <code>k#deref</code> in nightly to be able to avoid these conversations for a while is one of advantages I put in the draft <a href="https://github.com/scottmcm/rfcs/blob/never-preemptively-reserve-keywords/text/0000-raw-keywords.md#motivation">https://github.com/scottmcm/rfcs/blob/never-preemptively-reserve-keywords/text/0000-raw-keywords.md#motivation</a> )</p>



<a name="229558593"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229558593" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229558593">(Mar 09 2021 at 21:38)</a>:</h4>
<p>Keyword or sigil, it would be great to preserve the pattern/expression duality in some way- <code>box</code> patterns+expressions do this, <code>&amp;</code> patterns+expressions do this, but <code>ref</code> is a binding mode (i.e. only applies to identifiers) with no expression analog.</p>
<p>The tricky thing here, as I see it, is there is not one single expression counterpart-  <code>Box::new</code>, <code>Rc::new</code>, <code>&amp;</code>, etc. are all individual cases that "add" a deref-able thing that a deref pattern would match. (TBH, if <code>ref</code> didn't already exist, this would make it a good candidate here!)</p>



<a name="229559123"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229559123" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229559123">(Mar 09 2021 at 21:42)</a>:</h4>
<p>Another form of consistency that would be good to preserve is interaction with default binding modes. That is, in the main "by-move" "2015-compatible" mode, indirections should be considered part of the scrutinee's structure and represented in the pattern (i.e. using the keyword/sigil), and they should disappear from patterns in precisely the same way- by switching default binding modes.</p>
<p>(IMO "no sigil for literals, sigil for non-literals" breaks this, because literal-vs-not is a subtly different distinction than the one currently used for switching binding modes.)</p>



<a name="229569727"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229569727" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229569727">(Mar 09 2021 at 22:43)</a>:</h4>
<p>with regard to preserving the pattern/expression duality, is having a counterpart in expression position for this still desirable? indeed one of the original goals of the <code>box</code> keyword would be that you could construct <code>Box</code>, <code>Rc</code>, etc. with <code>box foo</code>, but it feels like the idea of having a generic "smart pointer constructor" keyword has been long since abandoned.</p>



<a name="229571297"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229571297" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229571297">(Mar 09 2021 at 22:56)</a>:</h4>
<p>I'm less interested in actually <em>having</em> a generic smart pointer constructor, and more interested in making the deref pattern fit the duality. So e.g. "deref" feels "backwards" here because a "deref" isn't part of the structure of anything, while "box" or "&amp;" or "ref" (in an alternative timeline at least) feel like they follow the same rules as other patterns.</p>



<a name="229575596"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229575596" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229575596">(Mar 09 2021 at 23:31)</a>:</h4>
<p>sure, if we're just thinking about keywords here then a verb like "deref" would be a bad choice; you'd want to represent this concept with a noun like <code>ptr</code> or something</p>



<a name="229575968"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229575968" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229575968">(Mar 09 2021 at 23:34)</a>:</h4>
<p>A thought: it's already idiomatic to invoke autoderef by adding an extra <code>&amp;</code> (like <code>foo(&amp;some_box)</code> where <code>fn foo(x: Box&lt;T&gt;)</code>), and further <code>&amp;</code> is already the sigil that you can elide with default binding modes, so maybe <code>&amp;</code> itself would be a good general-purpose deref pattern?</p>



<a name="229576039"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229576039" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229576039">(Mar 09 2021 at 23:34)</a>:</h4>
<p>that's mentioned as one of the options in the proposal, I'm still unsure how I feel about it</p>



<a name="229576357"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229576357" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229576357">(Mar 09 2021 at 23:37)</a>:</h4>
<p>it still feels kinda... backwards. which is to say, if you actually had <code>box &lt;pattern&gt;</code>, you might prefer to make it work with references (what are they if not smart pointers?) and use that to replace <code>&amp;&lt;pattern&gt;</code></p>



<a name="229576518"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229576518" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> bstrie <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229576518">(Mar 09 2021 at 23:38)</a>:</h4>
<p>but overall it's not the worst idea</p>



<a name="229583284"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229583284" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Josh Triplett <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229583284">(Mar 10 2021 at 00:47)</a>:</h4>
<p>To me, something like <code>match some_string { &amp;SOME_STR =&gt; ... }</code> seems backwards; if you were going to apply <code>&amp;</code> to something, it'd be <code>some_string</code> not <code>SOME_STR</code>.</p>



<a name="229587428"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229587428" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Joshua Nelson <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229587428">(Mar 10 2021 at 01:33)</a>:</h4>
<p>Why? some_string is a struct, not a reference.</p>



<a name="229589425"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229589425" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> Daniel Henry-Mantilla <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229589425">(Mar 10 2021 at 01:57)</a>:</h4>
<p>The case of <code>str</code>ings is a bit weirder in that we never have true <code>str</code>s <code>const</code>ants nor patterns (we only have <code>&amp;str</code>s).<br>
Should we have: <code>const SOME_STR: str = *"…";</code>, then we could write:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">if</span><span class="w"> </span><span class="fm">matches!</span><span class="p">(</span><span class="o">*</span><span class="s">"hi"</span><span class="p">,</span><span class="w"> </span><span class="n">SOME_STR</span><span class="w"> </span><span class="o">|</span><span class="w"> </span><span class="o">*</span><span class="s">"foo"</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
<span class="c1">// and thus:</span>
<span class="k">if</span><span class="w"> </span><span class="fm">matches!</span><span class="p">(</span><span class="s">"hi"</span><span class="p">,</span><span class="w"> </span><span class="o">&amp;</span><span class="n">SOME_STR</span><span class="w"> </span><span class="o">|</span><span class="w"> </span><span class="o">&amp;*</span><span class="s">"foo"</span><span class="p">)</span><span class="w"> </span><span class="p">{</span><span class="w"></span>
</code></pre></div>
<ul>
<li>Where <code>*</code> would be the generalization of <code>ref</code> for "arbitrary expressions" <span class="user-mention" data-user-id="117495">@rpjohnst</span> was talking about (although I won't personally be naming that "<code>ref</code>").</li>
</ul>
<p>At that point matching a <code>&amp;str</code> scrutinee leads to <code>&amp;*&lt;pattern of type &amp;str&gt;</code> being the most explicit syntax, and needing to write that for <code>String</code> would, at the cost of some sigil noise, lead to the most consistent logic / mental model:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="fm">matches!</span><span class="p">(</span><span class="n">some_string</span><span class="p">,</span><span class="w"> </span><span class="o">&amp;*</span><span class="s">"foo"</span><span class="p">)</span><span class="w"></span>
</code></pre></div>
<ul>
<li>Aside: the noise here comes from <code>"…"</code> in Rust carrying an implicit <code>&amp;</code> (and since we were talking about parallel universes: one with <code>&amp;"string literals"</code> could have been interesting… and noisy <span aria-label="big smile" class="emoji emoji-1f604" role="img" title="big smile">:big_smile:</span> ).</li>
</ul>
<p>The sigil noise can then be solved with our good old match ergonomics: <strong>deref patterns shouldn't be incompatible with those</strong>, it's just that having a sigil / keyword becomes especially <em>necessary</em> when <em>binding</em> values, while remaining <em>optional</em> for those who would want extra explicit indirection syntax.</p>
<ul>
<li>Example of a binding: <code>match get_string() { &amp;*(s @ ("foo" | "bar")) =&gt; … }</code></li>
</ul>
<p>This whole thing may look weird but, again, it's the most <em>consistent</em> model:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">match</span><span class="w"> </span><span class="n">get_string</span><span class="p">()</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="o">&amp;*</span><span class="p">(</span><span class="n">s</span><span class="w"> </span><span class="o">@</span><span class="w"> </span><span class="p">(</span><span class="s">"foo"</span><span class="w"> </span><span class="o">|</span><span class="w"> </span><span class="s">"bar"</span><span class="p">))</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"></span>
<span class="c1">// move the `&amp;` from rhs pattern to lhs scrutinee (`*`):</span>
<span class="k">match</span><span class="w"> </span><span class="o">*</span><span class="n">get_string</span><span class="p">()</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="o">*</span><span class="p">(</span><span class="n">s</span><span class="w"> </span><span class="o">@</span><span class="w"> </span><span class="p">(</span><span class="s">"foo"</span><span class="w"> </span><span class="o">|</span><span class="w"> </span><span class="s">"bar"</span><span class="p">))</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"></span>
<span class="c1">// move the `*` from rhs pattern to lhs scrutinee (`&amp;` or `&amp;mut` based on further usage):</span>
<span class="k">match</span><span class="w"> </span><span class="o">&amp;*</span><span class="n">get_string</span><span class="p">()</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="n">s</span><span class="w"> </span><span class="o">@</span><span class="w"> </span><span class="p">(</span><span class="s">"foo"</span><span class="w"> </span><span class="o">|</span><span class="w"> </span><span class="s">"bar"</span><span class="p">)</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"></span>
</code></pre></div>
<p><span class="user-mention" data-user-id="239881">@Josh Triplett</span> in the case of <code>String</code> we may have been used to just putting a single <code>&amp;</code> on scrutinee position and let auto-<code>Deref</code> take care of the actual magic:<br>
should we be using only one sigil in ParallelUniverseRust, we'd be writing:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">match</span><span class="w"> </span><span class="o">*</span><span class="n">s</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="s">"foo"</span><span class="w"> </span><span class="c1">// compare against a read-dereference of our `String` (or `&amp;str`, it doesn't matter)</span>
</code></pre></div>
<hr>
<p>And obviously feel free to imagine these examples with <code>box</code> or <code>k#deref</code> instead of <code>&amp;</code>:</p>
<div class="codehilite" data-code-language="Rust"><pre><span></span><code><span class="k">match</span><span class="w"> </span><span class="n">get_string</span><span class="p">()</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="k">box</span><span class="w"> </span><span class="o">*</span><span class="p">(</span><span class="n">s</span><span class="w"> </span><span class="o">@</span><span class="w"> </span><span class="p">(</span><span class="s">"foo"</span><span class="w"> </span><span class="o">|</span><span class="w"> </span><span class="s">"bar"</span><span class="p">))</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"></span>
<span class="k">match</span><span class="w"> </span><span class="n">get_string</span><span class="p">()</span><span class="w"> </span><span class="p">{</span><span class="w"> </span><span class="n">deref</span><span class="w"> </span><span class="o">*</span><span class="p">(</span><span class="n">s</span><span class="w"> </span><span class="o">@</span><span class="w"> </span><span class="p">(</span><span class="s">"foo"</span><span class="w"> </span><span class="o">|</span><span class="w"> </span><span class="s">"bar"</span><span class="p">))</span><span class="w"> </span><span class="o">=&gt;</span><span class="w"></span>
</code></pre></div>



<a name="229596889"></a>
<h4><a href="https://rust-lang.zulipchat.com#narrow/stream/281601-project-deref-patterns/topic/Deref%20Patterns%20%28but%20now%20a%20project%20group%29/near/229596889" class="zl"><img src="https://rust-lang.github.io/zulip_archive/assets/img/zulip.svg" alt="view this post on Zulip" style="width:20px;height:20px;"></a> rpjohnst <a href="https://rust-lang.github.io/zulip_archive/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group).html#229596889">(Mar 10 2021 at 03:31)</a>:</h4>
<p><span class="user-mention silent" data-user-id="239881">Josh Triplett</span> <a href="#narrow/stream/281601-project-deref-patterns/topic/Deref.20Patterns.20(but.20now.20a.20project.20group)/near/229583284">said</a>:</p>
<blockquote>
<p>To me, something like <code>match some_string { &amp;SOME_STR =&gt; ... }</code> seems backwards; if you were going to apply <code>&amp;</code> to something, it'd be <code>some_string</code> not <code>SOME_STR</code>.</p>
</blockquote>
<p>This immediately brings to mind the <code>IntoIterator</code> impls for things like <code>&amp;Vec&lt;T&gt;</code> vs <code>Vec&lt;T&gt;</code>, but i'm not sure i really understand why this makes sense. <code>&amp;some_string</code> having type <code>&amp;String</code> means the pattern would be doing <em>two</em> derefs, one old-style and one new-style, wouldn't it? what's the purpose of the extra old-style deref?</p>



<hr><p>Last updated: Aug 07 2021 at 22:04 UTC</p>
</html>